-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
Enable TypeScript strictNullChecks
#35843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Too many |
|
Might be possible to move up the Also, I don't think we should relax any of the |
| const refStyle = window.getComputedStyle(styleElement.value); | ||
| const refAltStyle = window.getComputedStyle(altStyleElement.value); | ||
| const refStyle = window.getComputedStyle(styleElement.value!); | ||
| const refAltStyle = window.getComputedStyle(altStyleElement.value!); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's right to keep adding ! everywhere.
If you are refactoring, then it should follow the best practice and make the code readable / maintainable -- unless you will do quick following up changes to fix them in short time.
Just like the "jQuery removal", adding a lot ? only makes code difficult to read or maintain. At last I have to clean up them one by one to really finish the refactoring.
For this one, maybe the proper fix is to use useTemplateRef<T>
And a lot of other places also need a proper fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is better to try to ensure stuff is non-nullable in first place, I will see what I can do, but some stuff like DOM queries are unfixable without major refactors that adds ifs everywhere and I think I will defer that to later and keep the !.
A big step towards enabling strict mode in Typescript.
There was definitely a good share of potential bugs while refactoring this. When in doubt, I opted to keep the potentially broken behaviour. Notably, the
DOMEventtype is gone, it was broken and we're better of with type assertions one.target.